The present invention relates generally to communicating information between computers, and more particularly to using a manager device to remotely manage multiple network security devices.
As computer systems and other network devices (e.g., printers, modems, and scanners) have become increasingly interconnected, it is increasingly important to protect sensitive information (e.g., confidential business data, access information such as passwords, or any type of data stored on certain devices) stored on one network device from unauthorized retrieval by other network devices. The prevalence of the Internet and the growth of the World Wide Web have only exacerbated this issue.
One way to address this issue involves the use of network security devices (xe2x80x9cNSDsxe2x80x9d) which attempt to control the spread of sensitive information so that only authorized users or devices can retrieve such information. Some types of NSDs, such as firewalls and security appliances, have a group of one or more trusted network devices (or networks consisting of trusted network devices) which the NSD attempts to protect from unauthorized external access. These NSDs monitor network information passing between external network devices and the devices in their group of trusted or internal devices. In addition, these NSDs typically implement a specified security policy by preventing the passage of unauthorized network information between the external and the trusted devices.
Those skilled in the art will appreciate that network information can be transmitted in a variety of formats. For example, network information is often transmitted as a series of individual packets of information, such as TCP/IP (Transfer Control Protocol/Internet Protocol) packets. While such packets will typically include the network address (e.g., IP address) of the device to receive the information, other data about the network information (e.g., the specific type of information being requested or sent) may be difficult to ascertain.
While a properly configured NSD can protect information stored on or accessible from trusted devices, it can be difficult to configure NSDs so that they correctly implement the desired security policies. One source of difficulty in configuring NSDs arises from the large number of types of network information which may be encountered. For example, there are a large number of network services and protocols which external devices may attempt to provide to trusted devices or access from trusted devices.
Such network services and protocols include, but are not limited to, Archie, auth (ident), DCE-RPC (Distributed Computing Environment Remote Procedure Call), DHCP (Dynamic Host Configuration Protocol) Client and Server, DNS (Domain Name Service), finger, FTP (File Transfer Protocol), gopher, H.323, HTTP (HyperText Transfer Protocol), Filtered-HTTP, Proxied-HTTP, ICMP (Internet Control Message Protocol), NNTP (Network News Transfer Protocol), NTP (Network Time Protocol), ping, POP (Post Office Protocol) 2 and 3, RealNetworks, rlogin, rsh (Remote SHell), SMB (Simple Block Messaging), SMTP (Simple Mail Transfer Protocol), SNMP (Simple Network Management Protocol), syslog, ssh (Secure SHell), StreamWorks, TCP/IP, telnet, Time, traceroute, UDP (User Datagram Protocol), VDOLive, WAIS (Wide Area Information Services), whois, and other device-specific services. Those skilled in the art will appreciate the uses and details of these services and protocols, including the device ports typically used with the services and protocols and the specified format for such information (e.g., the TCP/IP packet definition).
Another source of difficulty in configuring NSDs arises from the variety of ways to handle network information of different types. For example, for each type of service or protocol, a NSD may wish to take different actions for (e.g., allow passage of, deny passage of, or otherwise manipulate) the corresponding network information of that service or protocol. The decision to take these different actions can also be based on additional factors such as the direction of information flow (i.e., whether the network information is passing from a trusted device or to a trusted device) or on the basis of the sender or the intended recipient of the information (e.g., whether the network information is passing from or to specific network devices or is passing from or to any network device of a specified class, such as any external device).
The types of actions to be taken for the monitored network information (based on the various factors such as the services and protocols being used, the direction of the information flow, and the classes of devices of the sender and the intended recipient) provide an initial incomplete security policy. Various device-specific information is necessary to configure a particular NSD with a specific security policy that can be implemented by the device. The device-specific information which must typically be specified to create a specific security policy includes, for example, the network address of the NSD and the network addresses of some or all of the trusted devices. If a particular network service is to be provided to external devices by a trusted device, such as FTP access, information about the trusted FTP server must also be available to the NSD.
A user such as a system administrator typically defines the specific security policy for a NSD by determining the services and protocols of interest and then configuring the NSD to protect the trusted devices as appropriate. However, configuring an NSD can be time-consuming, and any mistakes in the configuration (e.g., failure to define how a particular service should be handled, or allowing default behaviors to allow passage of network information) can compromise the ability of the NSD to protect sensitive information. Thus, the need for system administrators to configure each NSD can cause various problems.
When it is necessary to configure large numbers of NSDs, such problems are only exacerbated. If the security policies across some or all of the NSDs should be consistent (e.g., multiple devices in use by a single company), the likelihood of mistakes increases. If the system administrator merely copies the specific security policy from one NSD to another, mistakes may occur in re-specifying the various NSD-specific configuration information. Alternately, if the system administrator attempts to re-create the general security policy independently on each NSD, various mistakes may occur such as neglecting to configure a type of service or incorrectly configuring the actions for such a type.
In addition to implementing security policies which may restrict the passage of some network information, NSDs typically gather network security information about events of interest, including encountering types of network information that is encountered as well as various actions taken by the NSD. The network security information can be displayed to users such as system administrators so that they can verify that the security policy is correctly implemented, produce reports about the types and quantities of network information that is allowed to pass and that is blocked from passage, and identify when external activities of concern (e.g., a hacker attack on the NSD) are occurring. NSDs typically maintain a local storage, often referred to as a log, of the security information that they gather.
Some NSDs include computer software components executing on general-purpose or dedicated computer hardware. For such an NSD, the executing software components assist in implementing the specific security policies defined for the NSD. Use of software components allows the operation of the NSD to be upgraded in an efficient manner by replacing some or all of the existing software components with new software components. Such new software is typically distributed via physical media such as CDs or optical disks, and is loaded onto the NSD by an individual such as a system administrator.
Some embodiments of the present invention provide a facility for using a security policy manager device to remotely manage multiple network security devices (NSDs). In some embodiments, the manager device uses one or more intermediate supervisor devices to assist in the management. Security for the communications between the manager device, supervisor devices, and NSDs can be provided in a variety of ways.
The facility allows the manager device to create a consistent security policy for the multiple NSDs by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information. For example, the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template. Other information useful for implementing security policies for the NSDs, such as software components to be executed by the NSDs, can also be distributed by the manager device to the NSDs in a similar manner.
The facility also allows a manager device to retrieve, analyze and display the network security information gathered by the various NSDs while implementing security policies. Each NSD can forward its network security information to a supervisor device currently associated with the NSD, and can switch supervisor devices if the current supervisor device becomes unavailable. When the manager device desires the network security information for an NSD, the manager device contacts the one or more supervisor devices which store portions of the network security information of interest, retrieves the various portions of the network security information, and then aggregates the retrieved information in an appropriate manner.